docs: define multi-organisational maintainer minimums and vendor neutrality cap#4
docs: define multi-organisational maintainer minimums and vendor neutrality cap#4dsterz wants to merge 1 commit intoneonephos:mainfrom
Conversation
…rality cap To ensure the long-term sustainability of our projects, we need to mitigate the "bus factor"—the risk that a project might stall if a single leader or company withdraws. I propose we restore the requirement for cross-organisational collaboration, which aligns nicely with open-source best practices. This requirement is crucial for fulfilling NeoNephos goal of prioritizing "independence from proprietary components and from single vendor owned open source projects". Mandating a diverse, multi-organisational maintainer base guarantees that "contribution and proven technical leadership matter more than company affiliation," helping us prevent vendor lock-in and uphold European digital sovereignty. Signed-off-by: David Sterz <opensource@davidsterz.de>
jakobmoellerdev
left a comment
jakobmoellerdev
left a comment
There was a problem hiding this comment.
love this suggestion!
| ##### Acceptance Criteria | ||
|
|
||
| The TAC has not yet defined requirements for the Growth Stage. | ||
| * The project must demonstrate a substantial ongoing flow of commits and merged contributions, driven by a minimum of three active maintainers from at least two different organisations |
There was a problem hiding this comment.
substantial is relative and should be put into absolute terms
There was a problem hiding this comment.
Given that the policy already defines an annual project review, this topic should be consolidated into that section. As part of that review, the TAC may move projects with little or no activity, regardless of stage, to the Emeritus stage.
For Growth Stage acceptance, the primary additional criterion should be a minimum number of active maintainers and organizations. The policy should also clarify what happens if the number of maintainers or participating organisations falls below the threshold, including how "active" is defined, the measurement period, and the timespan over which compliance is assessed.
For reference, some foundations require quarterly reports with basic activity statistics; adopting a similar cadence would provide clear, regular checkpoints.
There was a problem hiding this comment.
The TAC can monitor this via LFX Insights, so I don't think the project would need to build out the report. If the TAC sees concerns, it can go back to the TSC.
I will say quartely is probably too short of a period of time; projects tend to be seasonal. The annual review checkpoint @fmui mentioned is what I tend to see most often and provides a consistent snapshot of activities.
| ##### Acceptance Criteria | ||
|
|
||
| The TAC has not yet defined requirements for the Graduated Stage. | ||
| * The project must have a defined governing body (TSC or equivalent) of which no single organisation holds a majority (>50%) of the voting seats |
There was a problem hiding this comment.
While I understand why we could want this it is difficult to achieve. For voting purposes, you usually want an uneven number of participants in a committee. This implies that you needs members of at least three companies.
Why do we not state that there should be a TSC with at least members of two companies?
There was a problem hiding this comment.
So the Governing Body would always be a TSC - as that is in each project's Techincal Charter.
I think the majority statement as-is makes sense; yes ideally you want an odd number, but the bigger thing is you want the project not single vendor dominated.
|
Just for transparency reason. I had a call with @dsterz and we agreed that he will go over these PRs and push for less ambiguity here so we can safely get the very cool ideas he pushed for in |
|
Dear Group,
I want to confirm the statement from Jakob, and will provide my updates
beginning of next week, working on all 4 PRs, this week i am
unfortunately kept in urgent matters i have to finish first and
optimistic that we can reach conclusion for those quite fast.
Best regards
David
…On 04.05.26 08:03, Jakob Möller wrote:
*jakobmoellerdev* left a comment (neonephos/guidelines-development#4)
<#4 (comment)>
Just for transparency reason. I had a call with @dsterz
<https://github.com/dsterz> and we agreed that he will go over these
PRs and push for less ambiguity here so we can safely get the very
cool ideas he pushed for in
—
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABJ6ZN5FNBEAQGDY4NELGUT4ZAXBPAVCNFSM6AAAAACXB7QR6OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGNRYGY2DONBYGQ>.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
6 participants
To ensure the long-term sustainability of our projects, we need to mitigate the "bus factor"—the risk that a project might stall if a single leader or company withdraws.
I propose we restore the requirement for cross-organisational collaboration, which aligns nicely with open-source best practices.
This requirement is crucial for fulfilling NeoNephos goal of prioritizing "independence from proprietary components and from single vendor owned open source projects".
Mandating a diverse, multi-organisational maintainer base guarantees that "contribution and proven technical leadership matter more than company affiliation," helping us prevent vendor lock-in and uphold European digital sovereignty.